[レポート] STG304: Amazon EC2インスタンス、リレーショナルデータベース、NoSQLの作業を保護 #reinvent

はじめに

こんにちは、コンサル部の望月です。

ということで、AWS re:Invent 2018のセッション「STG304: Protecting Amazon EC2 Instances, Relational Databases, and NoSQL Workloads」 のレポートをお送りします。

セッション概要

For many IT professionals, cloud data protection can be challenging. In this session, we explore options for protecting and restoring your Amazon EC2 instances, relational databases, and NoSQL databases, such as MongoDB and Cassandra. We show you how solutions such as Rubrik Cloud Data Management and Rubrik Datos IO augment your Amazon EC2 backup strategy, including lifecycle management of Amazon EBS snapshots and Amazon Machine Images (AMI), automation and simplification of Amazon EBS volume and file-level restores from Amazon EBS snapshots, and application-consistent backup and recovery for Oracle, Microsoft SQL Server, MongoDB, and Cassandra databases on Amazon EC2. This session is brought to you by AWS partner, Rubrik.

スピーカー

• Rob Nolen
  • Solutions Architect
• Kenneth Hui
  • Solutions Architect , Rubrik
• Bill Gurling
  • Cloud Solutions Architect , Rubrik

レポート

• アジェンダ
  • Amazon Elastic Block Store（Amazon EBS）スナップショット入門
  • Amazon Elastic Compute Cloud（Amazon EC2）作業負荷をRubrikで保護する
  • デモ
  • RubrikとAmazon EC2インスタンス保護の自動化と拡張
  • アクションの呼び出し
• Amazon Elastic Block Store（Amazon EBS）スナップショット入門
  • Amazon EC2 Instance Store
    • インスタンスのローカル
    • 非永続データストア
    • 複製されないデータ（デフォルト）
    • スナップショットのサポートなし
    • SSD or HDD
  • Amazon EBS
    • 永続ブロックストレージボリューム
    • Availability Zone内で自動的に複製
    • 特定の時点のスナップショットをサポート
    • 必要に応じてボリュームタイプを変更する
    • SSD or HDD
    • オートリカバリー
• Amazon EBS
  • Amazon EBSは永続的なブロックストレージで、個々のストレージボリュームを作成できる
  • これらのストレージボリュームは、さまざまなユースケースでAmazon EC2インスタンスに接続される。
    • bootボリューム
    • データ/ログボリューム
    • アプリケーション(エンタープライズアプリケーションやその他のツールなど)
• Amazon EC2 Auto Recovery
  • インスタンスごとのAmazon CloudWatch metric：StatusCheckFailed_System
  • Amazon CloudWatch Alarm トリガー
• Amazon EBS ボリュームタイプ＆パフォーマンス
  • SSDベース
    • io1
      • 99.9％の一貫したパフォーマンスが要求されるクリティカルなI/O集約型データベース
      • Relational Databases
    • gp2
      • 予測可能なベースラインとバーストを備えたほとんどの作業負荷のIOPSパフォーマンス
      • NoSQL Databases, OS bootボリューム
  • HDDベース
    • st1
      • 高スループットを必要とする大規模なデータおよび分析作業負荷（Amazon EMR、Hadoop、Kafka）
      • Big Data
    • sc1
      • 少ないスキャンを必要とする、コールドボリューム（コールドログの処理の作業負荷、Splunk）
      • メディア
• Amazon EBSのスナップショットの仕組み
  • 増分バックアップの説明
• スナップショットのユースケース
  • Amazon Machine Images（AMI）の作成と共有
  • point in time コピー
  • DR (AZ or リージョン)
  • データベースまたは他のサーバー環境のクローンを作成
• スナップショットの管理
  • すべてTAG付けする
  • Amazon EBS Snapshot Scheduler
  • Data Lifecycle Manager(DLM)
• 保護を自動化（AWSサービス）
  • Amazon CloudWatch
    • Amazon CloudWatchは、AWSクラウドリソース、およびAmazon Web Services（AWS）で実行するアプリケーションの監視サービス
  • AWS Lambda
    • AWS Lambdaでは、サーバーのプロビジョニングや管理を行わずにコードを実行できる。消費する計算時間だけを支払う
  • Amazon DynamoDB
    • Amazon DynamoDBは、任意のスケールで一貫した1桁のミリ秒のレイテンシを必要とするすべてのアプリケーションに、高速かつ柔軟なNoSQLデータベースサービスです
• Rubrik Cloudの紹介
  • https://www.rubrik.com/
• Rubrik Cloudのデータ管理について
  • バックアップソフトウェア
  • バックアップサーバ
  • バックアッププロキシ
  • レプリケーション
  • カタログデータベース
  • 重複除外メタデータ
  • バックアップストレージ
  • テープ
  • オフサイトアーカイブ
• Amazon EC2をRubrikで保護する
  • Rubrik Cloud製品
    • 1.CloudOut
      • Amazon Simple Storage Service(S3)によるデータ保持
    • 2.Cloud Clouster
      • クラウド上の作業の保護
    • 3.CloudOn
      • 作業のインスタンス化
    • 4.Native Amazon EC2 protection

• Datos IO: クラウドにおけるシンプルなNoSQLデータを保護
  • 規模の単純さ
    • 最大数百のNoSQLノードと数千のコレクションに対するRubrik-styleのシンプルさ
  • スケールアウトするCassandraのバックアップ
    • すべてのサイズ、スキーマ、および変更するenterprise Cassandraアプリに合わせて保護
  • スケールアウトするMongoDBのバックアップ
    • すべてのサイズ、スキーマ、および変更するenterprise MongoDBアプリに合わせて保護
• ユースケース
  • 自動データ保護
    • 1つのポリシーエンジンを使用して、作成から有効期限のスナップショットのライフサイクル管理を自動化する
  • 高速なファイルレベルの復元
    • 手動のスクリプトを削除する。予測検索でスナップショットやファイルをすばやく見つけて復元する
  • クロスリージョンとクロスゾーンの復元
    • 数回クリックするだけで、別のAvailability Zoneまたはリージョン内のAmazon EC2インスタンスのレプリカをインスタンス化できる。
  • データ管理の統一
    • 1つのソフトウェアプラットフォームで、オンプレミス、エッジ、およびクラウド環境全体のデータを管理する
• Rubrikによるスナップショットのファイルインデックス作成
  • Step 1
    • RubrikがAmazon EBSスナップショットとAMIを作成するためのcreate-image呼び出し
  • Step 2
    • RubrikはAmazon EBSスナップショットから一時的なAmazon EBSボリュームを作成します
  • Step 3
    • 一時的なAmazon EBSボリュームをマウントおよび索引付けする、一時的なRubrikインスタンスを起動します

• Rubrikによるファイル復元
  • Step 1
    • リカバリするファイルを含むAmazon EBSスナップショットを検索する
  • Step 2
    • Amazon EBSスナップショットからボリュームを作成する
  • Step 3
    • Amazon EBSボリュームをマウント
  • Step 4
    • ダウンロードするファイルを取得し、RubrikにURLを送信する
• バックグラウンド
  • Rubrikの顧客 - ハイブリッドクラウドを展開
  • 成熟したAWS consumer
  • アカウントおよびインスタンスレベルで適用されたSLA
  • 高度に自動化された環境
  • Desire Push vs. SLAの割り当てを引き出す
• 自動化、拡張するRubrik、Amazon EC2保護

• Deployment

  • AWS CloudFormation!
  • 機密性の高いパラメータ → AWS Systems Manager Parameter Store
  • 現在はVPC全体、将来の状態はVPCまたはVPC全体を選択
  • RubrikへのHTTPS接続が必要
    • 私たちがクラウドにいる場合、自動的にピアリングする
    • 手動VPNトンネル（クラウドにいない場合）
    • ここに改善の余地
    • Public API エンドポイント
• より深く知る - CloudWatch events
  • Amazon EC2タグを使用してインスタンスに適用されるSLAを指定する
  • Amazon CloudLog / Amazon CloudWatch Events経由でアプリケーションを起動する（プッシュ操作）
  • イベントパターンにより、Rubrik固有のタグが適用されたときにのみ実行される
• The payload - Amazon Lambda
  • Python logging moduleとAmazon CloudWatch Logsによるlogging
  • AWS Lambdaのroleを使用してBoto3経由でSSMからRubrikのクレジットを取得する
  • SLAドメイン名とAWSインスタンスIDは、CloudWatch eventに由来します（イベントが発生するために存在する必要があります）

まとめ

AWSサービスを利用したデータの保護、また、Rubrikのサービスを利用し、一貫したデータの保護について、学ぶことが出来ました。

実際にデモで、Rubrikのサービスを使っているところを見ましたが、スナップショット内のファイルをインデックス化することにより、ファイルの検索やバージョン管理っぽいことが行えるようで、Amazon EC2をメインで使っている場合は便利そうでした。